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Abstract 


This document describes a method for generating an aggregated 
pseudowire (PW) status message transmitted for a statically 
configured PW on a Multiprotocol Label Switching (MPLS) Label 
Switched Path (LSP) to indicate the status of one or more PWs carried 
on the LSP. 


The method for transmitting the PW status information is not new; 
however, this protocol extension allows a Service Provider (SP) to 
reliably monitor the individual PW status while not overwhelming the 
network with multiple periodic status messages. This is achieved by 
sending a single cumulative summary status verification message for 
all the PWs grouped in the same LSP. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8237. 
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Copyright Notice 


Copyright (c) 2017 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(https://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


When PWs use a Multiprotocol Label Switching (MPLS) network as the 
Packet Switched Network (PSN), they are set up using static label 
assignment per Section 4 of [RFC8077], and the PW status information 
is propagated using the method described in [RFC6478]. There are two 
basic modes of operation described in [RFC6478], Section 5.3: 

(1) periodic retransmission of non-zero status messages and (2) a 
simple acknowledgment of PW status (Section 5.3.1 of [RFC6478]). The 
LSP-level protocol described below applies to the case when 


Martini, et al. Standards Track [Page 3] 


RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017 


PW status is acknowledged immediately with a requested refresh value 
of zero (no refresh). In this case, the PW status refresh reduction 
protocol is necessary for several reasons, such as the following: 


i. The PW status refresh reduction protocol greatly increases the 
scalability of the PW status protocol by reducing the amount of 
messages that a Provider Edge (PE) needs to periodically send to 
its neighbors. 


ii. The PW status refresh reduction protocol will detect a remote PE 
restart. 


iii. If the local state is lost for some reason, the PE needs to be 
able to request a status refresh reduction from the remote PE. 


iv. The PW status refresh reduction protocol can optionally detect a 
remote PE provisioning change. 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


1.2. Terminology 
FEC: Forwarding Equivalence Class 
LDP: Label Distribution Protocol 
LSP: Label Switched Path 
MS-PW: Multi-Segment Pseudowire 
PE: Provider Edge 
PW: Pseudowire 
S-PE: Switching Provider Edge Node of MS-PW 
SS-PW: Single-Segment Pseudowire 


T-PE: Terminating Provider Edge Node of MS-PW 
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1.3. Notational Conventions 


All multiple-word atomic identifiers use underscores ("_") between 
the words to join the words. Many of the identifiers are composed of 
a concatenation of other identifiers. These are expressed using 
double-colon ("::") notation. 


Where the same identifier type is used multiple times ina 
concatenation, they are qualified by a prefix joined to the 
identifier by a dash ("-"). For example, Src-Node_ID is the Node_ID 
of a node referred to as "Src" ("Src" is short for "source"). 


The notation does not define an implicit ordering of the information 
elements involved in a concatenated identifier. 


2. PW Status Refresh Reduction Protocol 


The PW status refresh reduction protocol consists of a simple message 
that is sent at the LSP level, using the MPLS Generic Associated 
Channel (G-ACh) [RFC5586]. 


For a particular LSP where the PW status refresh reduction protocol 
is enabled, a PE using this protocol MUST send the PW status refresh 
reduction Message as soon as a PW is configured on that LSP. The 
message is then retransmitted at a locally configured interval 
indicated in the Refresh Timer field. If no acknowledgment is 
received, the protocol does not reach the ACTIVE state 

(Section 2.1.3), and the PE SHOULD NOT send any PW status messages 
with a Refresh Timer of zero as described in [RFC6478], 

Section 5.3.1. 


It is worth noting that no relationship exists between the locally 
configured timer for the PW status refresh reduction protocol and the 
individual PW status Refresh Timers. 


2.1. Protocol States 


The protocol can be in three possible states: INACTIVE, STARTUP, and 
ACTIVE. 


2.1.1. INACTIVE 


This state is entered when the protocol is turned off. This state is 
also entered if all PWs on a specific LSP are deprovisioned. 


Martini, et al. Standards Track [Page 5] 


RFC 8237 MPLS LSP PW Status Refresh Reduction October 2017 


2.1.2. STARTUP 


In this state, the PE transmits periodic PW status refresh reduction 
Messages with the Ack Session ID (Section 4) set to 0. The PE 
remains in this state until a PW status refresh message is received 
with the correct local Session ID in the Ack Session ID field. State 
can transition from the STARTUP state to the ACTIVE or INACTIVE 
state. 


22023: ¿ACTIVE 


This state is entered once the PE receives a PW status refresh 
reduction Message with the correct local Session ID in the Ack 
Session ID field within 3.5 times the Refresh Timer field value of 
the last PW status refresh reduction Message transmitted. This state 
is immediately exited in the following scenarios: 


i. A valid PW status refresh reduction Message is not received 
within 3.5 times the current Refresh Timer field value (assuming 
that a timer transition procedure is not in progress). 

New state: STARTUP. 


ii. A PW status refresh reduction Message is received with the wrong 
Ack Session ID field value or a zero Ack Session ID field value. 
New state: STARTUP. 


iii. All PWs using the particular LSP are deprovisioned, or the 
protocol is disabled. 
New state: INACTIVE. 
2.2. Timer Value Change Transition Procedure 
If a PE needs to change the value of the Refresh Timer field while 
the PW status refresh reduction protocol is in the ACTIVE state, the 


following procedure must be followed: 


i. A PW status refresh reduction Message is transmitted with the 
new timer value. 


ii. If the new value is greater than the original one, the PE will 
operate according to the new timer value immediately. 
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iii. If the new value is smaller than the original one, the PE will 
operate according to the original timer value for a period 
3.5 times the original timer value or until the first valid PW 
status refresh reduction Message is received. 


A PE receiving a PW status refresh reduction Message with a new 
timer value will immediately acknowledge the new value via a PW 
status refresh reduction Message and will start operating 
according to the new timer value. 


3. PW Status Refresh Reduction Procedure 


When the PW status refresh reduction protocol on a particular LSP is 
in the ACTIVE state, the PE can send all PW status messages, for PWs 
on that LSP, with a Refresh Timer value of zero. This greatly 
decreases the amount of messages that the PE needs to transmit to the 
remote PE because once the PW status message for a particular PW is 
acknowledged, further repetitions of that message are no longer 
necessary. 


To further reduce the amount of possible messages when an LSP starts 
forwarding traffic, care should be taken to permit the PW status 
refresh reduction protocol to reach the ACTIVE state quickly, and 
before the first PW status Refresh Timer expires. This can be 
achieved by using a PW status refresh reduction Message Refresh Timer 
value that is much smaller than the PW status message Refresh Timer 
value in use (Section 5.3.1 of [RFC6478]). 


If the PW status refresh reduction protocol session is terminated by 
entering the INACTIVE state or the STARTUP state, the PE MUST 
immediately resend all the previously sent PW status messages for 
that particular LSP for which the session was terminated. In this 
case, the Refresh Timer value MUST NOT be set to 0 and MUST be set 
according to the local policy of the PE router. Implementations MUST 
take care to avoid flooding the remote PE with a large number of PW 
status messages at once. If the PW status refresh reduction protocol 
session is terminated for administrative reasons and the local PE can 
still communicate with the remote PE, the local PE SHOULD pace the 
transmission of PW status messages to the remote PE. 
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4. PW Status Refresh Reduction Message Encoding 


The packet containing the PW status refresh reduction Message is 
encoded as follows (omitting link-layer information): 


0 1 2 3 

00 T1 02.345.067 8:90:12 34 9 60-789 0. 12.3 4:05.6 8 090: 1 
a a e O 
| MPLS LSP (tunnel) Label Stack Entry | 
Fatt tata tata tata a o o o E O 
| GAL | 
Fatt tata tata a a o o o E E 
|o 0 0 1|Version Reserved | 0x29 PW OAM Message 
Fatt ata ta tata a o a o o o E 
| Session ID | Ack Session ID | 
FPP tata tata tartar tata a a o o O 
| Refresh Timer | Total Message Length 
Fatt tata tata tartar a a o o o o O 
| Checksum | Message Sequence Number | 
Fatt tata tata tartar o o o E O 
| Last Received Sequence Number | Message Type |u|C| Flags | 
a tartar a o AEA 
| | 


7 Control Message Body 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


This message contains the following fields: 
* MPLS LSP (tunnel) Label Stack Entry 
The label stack is explained in [RFC3031]. 
* GAL 
The G-ACh Label (GAL) and the next 4 octets (including the PW 
OAM Message field as the Channel Type) are explained in 
Section 2.1 of [RFC5586]. 


* PW OAM Message 


This field indicates the Channel Type in the G-ACh header, as 
described in Section 2.1 of [RFC5586]. 
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* Session ID 


A non-zero locally selected session number that is not 
preserved if the local PE restarts. 


In order to get a locally unique Session ID, the recommended 
choice is to perform a CRC-16 ("CRC" stands for "Cyclic 
Redundancy Check"), giving as input the following data: 


| yy | mam|DD|HEMMSSLLL | 


Where: 

YY = the last two decimal digits of the current year 

MM = the two decimal digits of the current month 

DD = the two decimal digits of the current day 

HHMMSSLLL = the decimal digits of the current time, 
expressed in hours (HH), minutes (MM), seconds (SS), and 
milliseconds (LLL) 


If the calculation results in an already-existing Session ID, a 
unique Session ID can be generated by adding 1 to the result 
until the Session ID is unique. Any other method to generate a 
locally unique Session ID is also acceptable. 

* Ack Session ID 
The Acknowledgment Session ID received from the remote PE. 

* Refresh Timer 
A non-zero unsigned 16-bit integer value greater than or equal 
to 10, expressed in milliseconds, that indicates the desired 
refresh interval. The default value of 30000 is RECOMMENDED. 

* Total Message Length 
Total length in octets of the Checksum, Message Type, Flags, 
Message Sequence Number, and Control Message Body. A value of 


zero means that no control message is present and, therefore, 
that no Checksum or subsequent fields are present either. 
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Checksum 


A 16-bit field containing the one’s complement of the one's 
complement sum of the entire message (including the G-ACh 
header), with the Checksum field replaced by zero for the 
purpose of computing the checksum. An all-zero value means 
that no checksum was transmitted. Note that when the checksum 
is not computed, the header of the bundle message will not be 
covered by any checksum. 


Message Sequence Number 


An unsigned 16-bit integer that is started from 1 when the 
protocol enters the ACTIVE state. The sequence number wraps 
back to 1 when the maximum value is reached. The value 0 is 
reserved and MUST NOT be used. 


Last Received Message Sequence Number 


The sequence number of the last message received. If no 
message has yet been received during this session, this field 
is set to 0. 


Message Type 


The type of control message that follows. Control message 
types are allocated in this document and by IANA. 


(U) Unknown flag bit 


Upon receipt of an unknown message or TLV, if U is clear (0), 

a notification message with code "Unknown TLV (U-Bit=0)" 

(code 0x4) MUST be sent to the remote PE, and the keepalive 
session MUST be terminated by entering the STARTUP state; if 

U is set (1), the unknown message, or message containing an 
unknown TLV, MUST be acknowledged and silently ignored, and the 
following messages, or TLVs, if any, processed as if the 
unknown message or TLV did not exist. In this case, the PE MAY 
send back a single notification message per keepalive session 
with code "Unknown TLV (U-Bit=1)". This last step is OPTIONAL. 


(C) Configuration flag bit 
The C-Bit is used to signal the end of PW configuration 


transmission. If it is set, the sending PE has finished 
sending all of its current configuration information. 
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* Flags 


The remaining 6 bits of PW status refresh reduction Message 
Flags to be allocated by IANA. These unallocated bits MUST be 
set to 0 on transmission and ignored on reception. 


* Control Message Body 


The Control Message Body is defined in Section 5 and is 
specific to the type of message. 


It should be noted that the Checksum, Message Sequence Number, Last 
Received Message Sequence Number, Message Type, Flags, and Control 
Message Body are OPTIONAL. The Total Message Length field is used to 
parse how many optional fields are included. Hence, all optional 
fields that precede a specific field that needs to be included in a 
specific implementation MUST be included if that optional field is 
also included. 


If any of the above values are outside the specified range, a 
notification message is returned with code "PW configuration not 
supported", and the message is ignored. 


5. PW Status Refresh Reduction Control Messages 
PW status refresh reduction Control Messages consist of the Checksum, 


Message Sequence Number, Last Received Message Sequence Number, 
Message Type, Flags, and Control Message Body. 


When a PW status refresh reduction Control Message needs to be sent, 
the system can attach it to a scheduled PW status refresh reduction 
Message or send one ahead of time. In any case, PW status refresh 
reduction Control Messages always piggyback on normal messages. 


A PW status refresh reduction Message is also called a PW status 
refresh reduction Control Message if it contains a control message 
construct. 


There can only be one control message construct per PW status refresh 
reduction Message. If the U-Bit is set and a PE receiving the PW 
status refresh reduction Message does not understand the control 
message, the control message MUST be silently ignored. However, the 
Message Sequence Number MUST still be acknowledged by sending a Null 
Notification message back with the appropriate value in the Last 
Message Received field. If a control message is not acknowledged 
after 3.5 times the value of the Refresh Timer, a fatal notification 
-- "Unacknowledged control message" -- MUST be sent, and the PW 
status refresh reduction session MUST be terminated. 
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If a PE does not want or need to send a control message, the Checksum 
and all subsequent fields MUST NOT be sent, and the Total Message 
Length field is then set to 0. 


5.1. Notification Message 


The most common use of the notification message is to acknowledge the 
reception of a message by indicating the received Message Sequence 
Number in the Last Received Sequence Number field. The notification 
message is encoded as follows: 


0 1 2 3 
Od: 23 3 6, 7008009001, 223 2 6 7:89 001 234,05: 06:10:89 01 
dd + + O $ hd $ de $ $ q — $ + q — d+ q +4 +++ +++ +++ +++ 
| Checksum | Message Sequence Number | 
t—+-+-4+-+-4+-4-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4+-4+-4-4-4+-4-4-4+-4-4-4 
| Last Received Sequence Number | Type=0x01 |u|c| Flags | 
dd + + q $ hd dd $ $ q — $ + q ++ q +4 +++ +++ +++ +++ 
| Notification Code | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- H+H 


The message type is set to 0x01, and the U-Bit is treated as 
described in Section 4. The Notification Codes are 32-bit quantities 
assigned by IANA (see the IANA Considerations section). Notification 
codes are considered either "Error codes" or simple notifications. 

If the Notification Code is an Error code as indicated in the IANA 
allocation registry, the keepalive session MUST be terminated by 
entering the STARTUP state. 


When there is no notification information to be sent, the 
notification code is set to 0 to indicate a "Null Notification". The 
C-Bit MUST always be set to 0 in this type of message. The remaining 
6 bits of PW status refresh reduction Message Flags are to be 
allocated by IANA. These unallocated bits MUST be set to 0 on 
transmission and ignored on reception. 


5.2. PW Configuration Message 


The PW status refresh reduction TLVs are informational TLVs that 
allow the remote PE to verify certain provisioning information. This 
message contains a series of sub-TLVs, in no particular order, that 
contain PW and LSP configuration information. The message has no 
preset length limit; however, its total length will be limited by the 
transport network’s Maximum Transmission Unit (MTU). PW status 
refresh reduction Messages MUST NOT be fragmented. If a sender has 
more configuration information to send than will fit into one PW 
Configuration Message, it may send additional messages carrying 
additional TLVs. 
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0 1 2 3 
OL 2 AOS O71 288 G0 1 253) 4 5 67 08:90 1:02 34 3.6: 7.890 4d 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Checksum | Message Sequence Number | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Last Received Sequence Number | Type=0x02 pu|cl Flags | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| PW Configuration Message Sub-TLVs 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The PW Configuration Message type is set to 0x02. For this message, 
the U-Bit is set to 1, as processing of these messages is OPTIONAL. 


The C-Bit is used to signal the end of PW configuration transmission. 
If it is set, the sending PE has finished sending all of its current 
configuration information. The PE transmitting the configuration 
MUST set the C-Bit on the last PW Configuration Message when all 
current PW configuration information has been sent. 


PW Configuration Message sub-TLVs have the following generic format: 


0 1 2 3 
01234567890123456789012345678090U1 
dh A A A A A O O o o o o +++ 

| Type | Length | Value 
dh A A A A A O O A A A A e dh o o o o o o +++ 


| Value (Continued) | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
5.2.1. MPLS-TP Tunnel ID 
This TLV contains the MPLS-TP Tunnel ID ("MPLS-TP" stands for "MPLS 
Transport Profile"). When the configuration message is used for a 


particular keepalive session, the MPLS-TP Tunnel ID sub-TLV MUST be 
sent at least once. 
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The MPLS-TP Tunnel ID is encoded as follows: 


0 1 2 3 
01.2345678901234567.8.900123450678901 
+ hh RO A dd dd e de de dd dd dd 4 4 4 4 + + + + + + ++ +++ 

| Type=0x01 | Length=20 | MPLS-TP Tunnel ID 
$ hh RO A A dd e e e de dd dd de de dd 4 4 + + + + + + + +++ 


| MPLS-TP Tunnel ID (Continued) (20 octets) | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The MPLS point-to-point tunnel ID is defined in [RFC6370]. The 
coding used by the node that is the source of a message is: 


Src-Global_Node_TD::Src-Tunnel_Num: :Dst-Global_Node_ID:: 
Dst-Tunnel_Num 


Note that a single tunnel ID is enough to identify the tunnel and the 
source end of the message. 


5.2.2. PW ID Configured List 


This OPTIONAL sub-TLV contains a list of the provisioned PWs on 
the LSP. 


0 1 2 3 
01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type=0x02 | Length | PW Path ID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| | 


| PW Path ID (Continued) | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The PW Path ID is a 32-octet PW path identifier [RFC6370]. The 
coding used by the node that is the source of a message is: 


AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID:: 
Dst-Global_ID::Dst-Node_ID::Dst-AC_ID 


The number of PW Path IDs in the TLV will be inferred by the length 


of the TLV, up to a maximum of 8. The procedure for processing this 
TLV will be described in Section 6. 
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5.2.3. PW ID Unconfigured List 


This OPTIONAL sub-TLV contains a list of the PWs that have been 
deprovisioned on the LSP. Note that sending the same PW address in 
both the PW ID Configured List sub-TLV and the PW ID Unconfigured 
List sub-TLV in the same configuration message constitutes a fatal 
session error. If this error occurs, an error notification message 
is returned with the Error code "PW Configuration TLV conflict", and 
the session is terminated by entering the STARTUP state. 


0 1 2 3 

Od EE E > 90 E E IE A OF 2B oO 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type=0x03 | Length | PW Path ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


PW Path ID (Continued) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The PW Path ID is a 32-octet PW path identifier as defined in 
Section 5.2.2. 


The number of PW Path IDs in the TLV will be inferred by the length 
of the TLV, up to a maximum of 8. 


6. PW Provisioning Verification Procedure 
The advertisement of the PW Configuration Message is OPTIONAL. 


A PE that desires to use the PW Configuration Message to verify the 
configuration of PWs on a particular LSP should advertise its PW 
configuration to the remote PE on LSPs that have active keepalive 
sessions. When a PE receives PW configuration information using this 
protocol and it does not support processing the information or is not 
willing to process it, it MUST acknowledge all the PW Configuration 
Messages with the notification code "PW configuration not supported". 
In this case, the information in the PW Configuration Message is 
silently ignored. If a PE receives such a notification, it SHOULD 
stop sending PW Configuration Messages for the duration of the PW 
status refresh reduction keepalive session. 
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If PW configuration information is received, it is used to verify the 
accuracy of the local configuration information against the remote 
PE’s configuration information. If a configuration mismatch is 
detected, where a particular PW is configured locally but not on the 
remote PE, the following actions SHOULD be taken: 


i. The local PW MUST be considered in "Not Forwarding" state 
(Section 6.3.2 of [RFC8077]). 


ii. The PW Attachment Circuit status is set to reflect the PW fault. 
iii. An alarm SHOULD be raised to a network management system. 


iv. A notification message with the notification code "PW 
configuration mismatch" MUST be sent to the remote PE. Only one 
such message is REQUIRED per configuration message even if the 
configuration message is split into multiple configuration 
messages due to individual message-size restrictions ona 
particular link. Upon receipt of such a message, the receiving 
PE MAY raise an alarm to a network management system. This 
alarm MAY be cleared when the configuration is updated. 


6.1. PW ID List Advertising and Processing 


When configuration messages are advertised on a particular LSP, the 
PE sending the messages needs to checkpoint the configuration 
information sent by setting the C-Bit when all currently known 
configuration information has been sent. This process allows the 
receiving PE to immediately proceed to verify all the currently 
configured PWs on that LSP, eliminating the need for a long waiting 
period. 


If a new PW is added to a particular LSP, the PE MUST place the 
configuration verification of this PW on hold for a period of at 
least 30 seconds. This is necessary to minimize false-positive 
events of misconfiguration due to the ends of the PW being slightly 
out of sync. 


7. Security Considerations 


The security considerations discussed in [RFC6478] are adequate for 
the mechanism described in this document, since the operating 
environment is almost identical to the one where this protocol would 
be deployed. It should also be noted that since this protocol is 
designed to be deployed between two adjacent PEs connected by a 
physical link, it is not possible to misdirect or inject traffic 
without compromising the PW transport link itself. 
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8. 


8. 


IANA Considerations 


The registries in this section have been created or updated as 
appropriate in the "Pseudowire Name Spaces (PWE3)" registry or the 
"Generic Associated Channel (G-ACh) Parameters" registry. For the 
allocation ranges designated as "vendor-proprietary extensions", the 
respective IANA registry contains the vendor name in brackets at the 
end of the Description field. 


PW Status Refresh Reduction Message Types 


IANA has set up the "PW Status Refresh Reduction Control Messages" 
registry. This registry contains 8-bit values. Type values 1 and 2 
are defined in this document. Type values 3 through 64 and 128 
through 254 are to be assigned by IANA using the "Expert Review" 
policy defined in [RFC8126]. Type values 65 through 127, 0, and 255 
are to be allocated using the "IETF Review" policy defined in 
[RFC8126]. 


The Type values are assigned as follows: 


Type Message Description 


0x01 Notification message 
0x02 PW Configuration Message 


.2. PW Configuration Message Sub-TLVs 


IANA has set up the "PW Status Refresh Reduction Configuration 
Message Sub-TLVs" registry. This registry contains 8-bit values. 
Type values 1 through 3 are defined in this document. Type values 4 
through 64 and 128 through 254 are to be assigned by IANA using the 
"Expert Review" policy defined in [RFC8126]. Type values 65 through 
127, 0, and 255 are to be allocated using the "IETF Review" policy 
defined in [RFC8126]. 


The Type values are assigned as follows: 


Sub-TLV Type Description 

0x01 MPLS-TP Tunnel ID 

0x02 PW ID Configured List 
0x03 PW ID Unconfigured List 
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8.3. PW Status Refresh Reduction Notification Codes 


IANA has set up the "PW Status Refresh Reduction Notification Codes" 
registry. This registry contains 32-bit values. Type values 0 
through 7 are defined in this document. Type values 8 through 65536 
and 134,217,729 through 4,294,967,294 are to be assigned by IANA 
using the "Expert Review" policy defined in [RFC8126]. Type values 
65537 through 134,217,728, 0, and 4,294,967,295 are to be allocated 
using the "IETF Review" policy defined in [RFC8126]. 


For each value assigned, IANA should also track whether the value 
constitutes an error as described in Section 5.1. When values are 
assigned by IETF Review, the settings in the "Error?" column must be 
documented in the RFC that requests the allocation. For 

"Expert Review" assignments, the settings in the "Error?" column must 
be made clear by the requester at the time of assignment. 


The Type values are assigned as follows: 


Code Error? Description 

0x00000000 No Null Notification 

0x00000001 No PW configuration mismatch 
0x00000002 Yes PW Configuration TLV conflict 
0x00000003 No Unknown TLV (U-Bit=1) 
0x00000004 Yes Unknown TLV (U-Bit=0) 
0x00000005 No Unknown Message Type 
0x00000006 No PW configuration not supported 
0x00000007 Yes Unacknowledged control message 


8.4. PW Status Refresh Reduction Message Flags 


TANA has set up the "PW Status Refresh Reduction Message Flags" 
registry. This is an 8-bit registry, with the first two most 
significant bits allocated by this document as follows: 


Bit Position Name Description 
0 U Unknown flag bit 
1 Ç Configuration flag bit 


The remaining bits are to be allocated using the "IETF Review" policy 
defined in [RFC8126]. 
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8.5. G-ACh Registry Allocation 


IANA maintains a registry called "MPLS Generalized Associated Channel 
(G-ACh) Types (including Pseudowire Associated Channel Types)". IANA 
has allocated a new value as follows: 


Value Description Reference 


0x29 PW Status Refresh Reduction RFC 8237 
8.6. Guidance for Designated Experts 


In all cases of review by the Designated Expert (DE) described here, 
the DE is expected to ascertain the existence of suitable 
documentation (a specification) as described in [RFC8126] and to 
verify that the document is permanently and publicly available. The 
DE is also expected to check that the clarity of purpose and use of 
the requested code points fit the general architecture and intended 
purpose of the respective message or TLV. Lastly, the DE should 
check that any assignment does not duplicate or conflict with work 
that is active or already published within the IETF. 
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